I JIK 


CSC-STD-002-8S 


DA*  1  »CT»r  h; 


DEPARTMENT  OF  DEFENSE 


PASSWORD  MANAGEMENT 


GUIDELINE 


Approved  for  public  release; 
distribution  unlimited. 


12  April  1985 


20040817  030 


DEPARTMENT  OF  DEFENSE 
COMPUTER  SECURITY  CENTER 
Fort  George  G.  Meade,  Maryland  20755 


CSC-STD-002-85 
Library  No.  S-226,994 


FOREWORD 


This  publication,  "Department  of  Defense  Password  Management  Guideline,”  is 
being  issued  by  the  DoD  Computer  Security  Center  (DoDCSC)  under  the  authority  of 
and  in  accordance  with  DoD  Directive  5215.1,  "Computer  Security  Evaluation 
Center.”  The  guidelines  described  in  this  document  provide  a  set  of  good  practices 
related  to  the  use  of  password-based  user  authentication  mechanisms  in  automatic 
data  processing  systems  employed  for  processing  classified  and  other  sensitive 
information.  Point  of  contact  concerning  this  publication  is  the  Office  of  Standards 
and  Products,  Attention:  Chief,  Computer  Security  Standards. 


Robert  L.  Brotzmai 
Director 
DoD  Computer  Security  Center 


12  April  1985 


ACKNOWLEDGMENTS 


Special  recognition  is  extended  to  Sheila  L.  Brand,  DoD  Computer  Security  Center 
(DoDCSC),  and  Jeffrey  D.  Makey,  formerly  DoDCSC,  as  principal  authors  of  this 
publication. 

Acknowledgment  is  also  given  for  the  contributions  of:  Daniel  J.  Edwards,  Mary  E. 
Flaherty,  Steven  J.  Padilla,  DoDCSC,  John  J.  Stasak  HI,  Gregory  L.  Wessel  and 
Bernard  Peters,  Department  of  Defense,  Col.  Roger  R.  Schell,  formerly  DoDCSC,  and 
James  P.  Anderson,  James  P.  Anderson  &  Co,  who  gave  generously  of  their  time  and 
expertise  in  the  formulation  and  review  of  this  document. 


ii 


CONTENTS 


FOREWORD . i 

ACKNOWLEDGMENTS . ii 

CONTENTS . iii 

INTRODUCTION . 1 

1.0  SCOPE . 1 

2.0  CONTROL  OBJECTIVES . 2 

3.0  DEFINTIONS . 3 

4.0  GUIDELINES . 4 

4.1  SSO  Responsibilities . 4 

4.1.1  Initial  System  Passwords . 4 

4.1.2  Initial  Password  Assignment . 4 

4.1.3  Password  Change  Authorization . 5 

4.1.4  Group  IDs . 6 

4.1.5  User  ID  Revalidation . 6 

4.2  User  Responsibilities . 6 

4.2.1  Security  Awareness . 6 

4.2.2  Changing  Passwords . 6 

4.2.3  Login  to  a  Connected  System . 8 

4.2.4  Remembering  Passwords . 8 

4.3  Authentication  Mechanism  Functionality . 9 

4.3.1  Internal  Storage  of  Passwords . 9 

4.3.2  Entry . 9 

4.3.3  Transmission . 10 

4.3.4  Login  Attempt  Rate . 10 

4.3.5  Auditing . 10 

4.4  Password  Protection . 11 

4.4.1  Single  Guess  Probability . 11 

4.4.2  Password  Distribution . 11 

APPENDIX  A:  Password  Generation  Algorithm . 13 

APPENDIX  B:  Password  Encryption  Algorithm . 15 

APPENDIX  C:  Determining  Password  Length . 17 


APPENDIX  D:  Protection  Basis  for  Passwords . 23 

APPENDIX  E:  Featuresfor  Use  in  Very  Sensitive  Applications.  ......  25 

APPENDIX  F:  On  the  Probability  of  Guessing  a  Password . 27 

REFERENCES . . . 31 


iv 


SECURITY  CLASSIFICATION  OF  THIS  PAGE 


REPORT  DOCUMENTATION  PAGE 


1«.  REPORT  SECURITY  CLASSIFICATION 

UNCLASSIFIED 

1b.  RESTRICTIVE  MARKINGS 

2*.  SECURITY  CLASSIFICATION  AUTHORITY 

3.  DISTRIBUTION/AVAILABILITY  OF  REPORT 

Public  Release-Distribution  Unlimited 

2b.  DECLASSIFICATION/DOWNGRADING  SCHEDULE 

4.  PERFORMING  ORGANIZATION  REPORT  N UMBER(S) 

5.  MONITORING  ORGANIZATION  REPORT  NUMBER(S) 

CSC-STD-002-85 

S«.  NAME  OF  PERFORMING  ORGANIZATION 

National  Computer  Security 
Center 

6b.  OFFICE  SYMBOL 
(If  applicable) 

Cl 

7*.  NAME  OF  MONITORING  ORGANIZATION 

6c.  ADDRESS  (City,  State  and  ZIP  Code) 

9800  Savage  Road 

Fort  George  G.  Meade,  MD  20755-6000 

7b.  ADDRESS  (City,  State  and  ZIP  Code)  - 

8*.  NAME  OF  FUNDING/SPONSORING 
ORGANIZATION 

8b.  OFFICE  SYMBOL 
(If  applicable) 

9.  PROCUREMENT  INSTRUMENT  IDENTIFICATION  NUMBER 

8c.  ADDRESS  (City,  State  and  ZIP  Code) 


10.  SOURCE  OF  FUNDING  NOS. 


PROGRAM 

PROJECT 

TASK 

WORK  UNIT 

ELEMENT  NO. 

NO. 

NO. 

NO. 

12.  PERSONAL  AUTHOR(S) 


13*.  TYPE  OF  REPORT 

Final 


18.  SUPPLEMENTARY  NOTATION 

S-226,994 


17.  COSATI  CODES 


13b.  TIME  COVERED 
FROM _  TO. 


14.  DATE  OF  REPORT  (Yr.,  Mo.,  Day)  15.  PAGE  COUNT 

1985,  April  12  36 


FIELD  GROUP 


18.  SUBJECT  TERMS  (Continue  on  reverte  if  necessary  and  identify  by  block  number ) 

Password  Passphrase  Identification  Authentication 


19.  ABSTRACT  (Continue  on  reverte  if  necessary  and  identify  6y  block  number) 

The  DoD  Password  Management  Guideline  provides  a  set  of  good  practices  directed 
toward  preventing  password  compromise.  Large  numbers  of  ADP  systems  require  identi¬ 
fication  and  authentication  of  a  system  user.  Often,  the  authentication  mechanism 
implemented  is  a  password — a  "symbol"  that  should  be  known  only  by  its  owner. 

Since  a  user’s  identification  is  often  a  compaction  of  the  individual’s  name  and 
thus  easily  guessed,  the  password  must  provide  the  requisite  protection.  Measures 
suggested  for  password  protection  include: 

a.  Use  of  machine-generated  pronounceable  passwords  (pass-phrases). 

b.  Maximum  length  of  time  for  password  retention. 

c.  Capability  to  change  a  password. 

d.  Personal  password  protection  (e.g.,  not  written  down). 


20.  DISTRIBUTION/AVAILABILITY  OF  ABSTRACT 
UNCLASSIFIED/UNLIMITED  B  SAME  AS  RPT.  □  DTIC  USERS  □ 


22*.  NAME  OF  RESPONSIBLE  INDIVIDUAL 

Sheila  L.  Brand,  Chief  Cll 


21.  ABSTRACT  SECURITY  CLASSIFICATION 

UNCLASSIFIED 


22b.  TELEPHONE  NUMBER  22c.  OFFICE  SYMBOL 

(Include  Area  Code) 

301-859-6591  Cll 


DD  FORM  1473, 83  APR 


EDITION  OF  1  JAN  73  IS  OBSOLETE. 


UNCLASSIFIED _ . 

SECURITY  CLASSIFICATION  OF  THIS  PAGE 


SECURITY  CLASSIFICATION  OF  THIS  PAGE 


19.  ABSTRACT  (Continued) 

e.  Minimum  number  of  characters  for  a  password. 

f.  Protection  of  password  data-base. 

g.  Exclusion  of  password  from  audit  trail. 

h.  Limiting  access  to  password  data-base. 

The  use  of  an  algorithm  that  provides  machine-generated  pronounceable 
passwords  is  advocated.  These  "passphrases"  would  be  user-friendly  in  contrast 
to  an  algorithm  that  provides  machine-generated  passwords  composed  of  a 
minimum  number  of  random  characters. 


SECURITY  CLASSIFICATION  OF  THIS  PAGE 


1 


INTRODUCTION 


In  August  1983,  the  DoD  Computer  Security  Center  published  CSC-STD-001-83, 
Department  of  Defense  Trusted  Computer  System  Evaluation  Criteria.  That 
publication  defines  and  describes  feature  and  assurance  requirements  for  six 
hierarchical  classes  of  enhanced  security  protection  for  computer  systems  that  are  to 
be  used  for  processing  classified  or  other  sensitive  information.  A  major  requirement 
common  to  all  six  classes  is  accountability: 

"Individual  accountability  is  the  key  to  securing  and 
controlling  any  system  that  processes  information  on  behalf 
of  individuals  or  groups  of  individuals.  A  number  of 
requirements  must  be  met  in  order  to  satisfy  this  objective. 

"The  first  requirement  is  for  individual  user  identification. 

Second,  there  is  a  need  for  authentication.  Without 
authentication,  user  identification  has  no  credibility. 

Without  a  credible  identity  (no) .  .  .  security  policies  can  be 
properly  invoked  because  there  is  no  assurance  that  proper 
authorizations  can  be  made."  (2) 

This  guideline  has  been  developed  to  assist  in  providing  that  much  needed 
credibility  of  user  identity  by  presenting  a  set  of  good  practices  related  to  the  design, 
implementation  and  use  of  password-based  user  authentication  mechanisms.  It  is 
intended  that  features  and  practices  described  in  this  guideline  be  incorporated  into 
DoD  automatic  data  processing  (ADP)  systems  used  for  processing  classified  or  other 
sensitive  information. 


1.0  SCOPE 

The  security  provided  by  a  password  system  depends  on  the  passwords  being  kept 
secret  at  all  times.  Thus,  a  password  is  vulnerable  to  compromise  whenever  it  is 
used,  stored,  or  even  known.  In  a  password-based  authentication  mechanism 
implemented  on  an  ADP  system,  passwords  are  vulnerable  to  compromise  due  to 
five  essential  aspects  of  the  password  system:  1)  a  password  must  be  initially 
assigned  to  a  user  when  enrolled  on  the  ADP  system;  2)  a  user’s  password  must  be 
changed  periodically;  3)  the  ADP  system  must  maintain  a  "password  database";  4) 
users  must  remember  their  passwords;  and  5)  users  must  enter  their  passwords 
into  the  ADP  system  at  authentication  time.  This  guideline  prescribes  steps  to  be 
taken  to  minimize  the  vulnerability  of  passwords  in  each  of  these  circumstances. 
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Specific  areas  addressed  in  this  guideline  include  the  responsibilities  of  the  system 
security  officer  and  of  users,  the  functionality  of  the  authentication  mechanism, 
and  password  generation.  The  major  features  advocated  in  this  guideline  are: 

*  Users  should  be  able  to  change  their  own  passwords. 

*  Passwords  should  be  machine-generated  rather  than  user-created. 

*  Certain  audit  reports  (e.g.,  date  and  time  of  last  login)  should  be 
provided  by  the  system  directly  to  the  user. 

For  certain  sensitive  applications  such  as  Command  and  Control  Systems, 
pertinent  DoD  directives  should  be  referenced  in  order  to  assess  the  need  for 
additional  identification  and  authentication  features. 


2.0  CONTROL  OBJECTIVES 

The  CSC-STD-001-83  gives  the  following  as  the  Accountability  Control  Objective: 

"Systems  that  are  used  to  process  or  handle  classified  or  other 
sensitive  information  must  assure  individual  accountability 
whenever  either  a  mandatory  or  discretionary  security  policy  is 
invoked.  Furthermore,  to  assure  accountability,  the  capability  must 
exist  for  an  authorized  and  competent  agent  to  access  and  evaluate 
accountability  information  by  a  secure  means,  within  a  reasonable 
amount  of  time,  and  without  undue  difficulty  ."  (2) 

In  order  to  attain  the  individual  accountability  required,  it  is  necessary  for  the 
ADP  system  to  be  able  to  uniquely  identify  each  person  who  uses  it.  In  many 
cases,  a  password  scheme  will  be  used  to  achieve  this.  The  Accountability 
Control  Objective,  applied  to  password  systems,  leads  to  the  following  control 
objectives  for  password  systems. 


*  Personal  Identification 

Password  systems  used  to  control  access  to  ADP  systems  that  process  or 
handle  classified  or  other  sensitive  information  must  assure  the  capability 
to  uniquely  identify  each  individual  user  of  the  system. 

*  Authentication 

Password  systems  used  to  control  access  to  ADP  systems  that  process  or 
handle  classified  or  other  sensitive  information  must  assure  unequivocal 
authentication  of  the  user’s  claimed  identity. 
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*  Password  Privacy 

Password  systems  must  assure,  to  the  extent  possible,  protection  of  the 
password  database  consistent  with  protection  afforded  the  classified  or 
other  sensitive  information  processed  or  handled  by  the  ADP  system  in 
which  the  password  systems  operate. 

*  Auditing 

Password  systems  used  to  control  access  to  ADP  systems  that  process  or 
handle  classified  or  other  sensitive  information  must  be  able  to  assist  in  the 
detection  of  password  compromise. 


3.0  DEFINITIONS 

*  Access  Port  -  A  logical  or  physical  identifier  that  a  computer  uses  to 
distinguish  different  terminal  input/output  data  streams. 

*  Expired  Password  -  A  password  that  must  be  changed  by  the  user  before 
login  may  be  completed. 

*  Password  -  A  character  string  used  to  authenticate  an  identity.  Knowledge 
of  the  password  that  is  associated  with  a  user  ID  is  considered  proof  of 
authorization  to  use  the  capabilities  associated  with  that  user  ID. 

*  Password  System  -  A  part  of  an  ADP  system  that  is  used  to  authenticate  a 
user’s  identity.  Assurance  of  unequivocal  identification  is  based  on  the  user’s 
ability  to  enter  a  private  password  that  no  one  else  should  know. 

*  System  Security  Officer  (SSO)  -  The  person  responsible  for  the  security  of 
an  ADP  system.  The  SSO  is  authorized  to  act  in  the  "security  administrator" 
role  defined  in  CSC-STD-001-83.  Functions  that  the  SSO  is  expected  to 
perform  include:  auditing  and  changing  security  characteristics  of  a  user. 

*  Trusted  Identification  Forwarding  -  An  identification  method  used  in 
networks  where  the  sending  host  can  verify  that  an  authorized  user  on  its 
system  is  attempting  a  connection  to  another  host.  The  sending  host 
transmits  the  required  user  authentication  information  to  the  receiving  host. 
The  receiving  host  can  then  verify  that  the  user  is  validated  for  access  to  its 
system.  This  operation  may  be  transparent  to  the  user. 

*  User  ID  -  A  unique  symbol  or  character  string  that  is  used  by  an  ADP  system 
to  uniquely  identify  a  user.  The  security  provided  by  a  password  system 
should  not  rely  on  secrecy  of  the  user’s  ID. 
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4.0  GUIDELINES 

In  the  remainder  of  this  document,  guidelines  for  good  practice  are  presented  in 
bold  print,  while  amplifications,  examples,  and  rationale  are  presented  in 
normal  print.  The  guidelines  are  given  with  two  degrees  of  emphasis.  Those 
that  are  most  important  to  the  security  of  a  password  system  are  presented  with 
such  wording  as  ’  The  SSO  should  . . ."  (the  word  "should”  is  the  key),  while  less 
critical  functions  are  presented  with  such  wording  as  "It  is  recommended  that 
. . ."  ("recommended"  is  the  key).  Because  it  is  anticipated  that  diverse  user 
communities  will  adopt  this  guideline,  all  recommendations  are  presented  in 
general  rather  than  specific  terminology,  divorced  from  vendor-specific 
hardware  or  system  software.  Where  features  require  the  setting  of  a  specific 
value  (e.g.,  password  maximum  lifetime),  it  is  suggested  that  these  be  designed 
as  parametric  settings  leaving  the  determination  of  exact  values  to  local 
security  management  who  understand  the  particular  security  requirements  of 
their  user  environment. 

It  is  recommended  that,  whenever  possible,  the  mechanisms  discussed  in 
this  guide  be  automated.  Automation  will  result  in  a  minimal  burden  on  the 
system  administration  and  on  the  users,  and  thus  in  greater  effectiveness  of  the 
mechanisms  by  eliminating  situations  where  passwords  might  be  exposed  to 
people. 


4.1  SSO  Responsibilities 

4.1.1  Initial  System  Passwords 

Many  ADP  systems  come  from  the  vendor  with  a  few  standard  user  IDs 
(e.g.,  SYSTEM,  TEST,  MASTER,  etc.)  already  enrolled  in  the  system. 
The  System  Security  Officer  (SSO)  should  change  the  passwords 
for  all  standard  user  IDs  before  allowing  the  general  user 
population  to  access  the  system.  This  can  be  easily  assured  if  the 
standard  user  IDs  are  initially  identified  by  the  system  as  having 
"expired"  passwords.  (See  section  4.2.2. 1  for  discussion  of  expired 
passwords.) 

4. 1.2  Initial  Password  Assignment 

The  SSO  is  responsible  for  generating  and  assigning  the  initial  password 
for  each  user  ID.  The  user  must  then  be  informed  of  this  password.  In 
some  areas,  it  may  be  necessary  to  prevent  exposure  of  the  password  to 
the  SSO.  In  other  cases,  the  user  can  easily  nullify  this  exposure. 

4. 1.2. 1  Preventing  Exposure 

There  are  methods  that  can  be  implemented  to  prevent  exposure  of  a 
password  to  the  SSO  after  it  has  been  generated. 

One  technique  is  to  print  the  user’s  password  on  a  sealed  multipart 
form  in  such  a  way  that  it  is  not  visible  on  the  top  page  of  the  form. 
The  SSO  would  then  protect  the  sealed  password  appropriately  until 
it  could  be  delivered  to  the  user.  In  this  case,  the  password  is 
generated  randomly  by  the  ADP  system  and  is  not  known  by  the  SSO. 
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The  password  should  be  sealed  so  it  is  not  visible  and  cannot  be 
made  visible  without  breaking  the  seal.  Delivery  of  the  password 
in  this  manner  could  require  several  days. 

Another  method  of  preventing  exposure  is  to  have  the  user  present  at 
password  generation.  The  SSO  must  initiate  the  procedure  and  the 
user  must  shield  the  generated  password  and  then  remove  or  erase  it 
from  the  display.  This  method  cannot  be  used  when  user  terminals 
are  at  remote  locations. 

It  is  recommended  that  a  technique  comparable  to  one  of  the 
above  be  used  to  prevent  exposing  a  user’s  initial  password  to 
the  SSO. 

Whatever  method  is  used  to  distribute  passwords,  the  SSO  must 
receive  an  acknowledgment  of  receipt  of  the  password  within  a 
specified  time  period. 

4.1. 2.2  Nullifying  Exposure 

When  a  user’s  initial  password  must  be  exposed  to  the  SSO,  this 
exposure  may  be  nullified  by  having  the  user  immediately  change  the 
password  by  the  normal  procedure.  (Presumably,  this  change 
procedure  does  not  expose  the  new  password  to  the  SSO.) 

When  a  user’s  initial  password  is  not  protected  from  exposure 
to  the  SSO,  the  user  ID  should  be  identified  by  the  system  as 
having  an  "expired  password"  which  will  require  the  user  to 
change  the  password  by  the  usual  procedure  (see  section 
4.2.2.3)  before  receiving  authorization  to  access  the  system. 

4.1. 2.3  Classification  Assignment 

Where  the  password  must  be  classified,  the  initial  classification 
assignment  should  be  entered  by  the  SSO  to  designate  the 
highest  security  level  that  may  be  associated  with  each  user’s 
initial  password  and  its  successors. 

4. 1.3  Password  Change  Authorization 

Occasionally,  a  user  will  forget  the  password  or  the  SSO  may  determine 
that  a  user’s  password  may  have  been  compromised.  To  be  able  to  correct 
these  problems,  it  is  recommended  that  the  SSO  be  permitted  to 
change  the  password  of  any  user  by  generating  a  new  one.  The 
SSO  should  not  have  to  know  the  user’s  password  in  order  to  do 
this,  but  should  follow  the  same  rules  for  distributing  the  new 
password  that  apply  to  initial  password  assignment  (see  section 
4.1.2).  Positive  identification  of  the  user  by  the  SSO  is  required  when  a 
forgotten  password  must  be  replaced. 
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4. 7.4  Group  IDs 

Throughout  the  lifetime  of  an  ADP  system,  each  user  ID  should  be 
assigned  to  only  one  person.  In  other  words,  no  two  people  may  ever 
have  the  same  user  ID  at  the  same  time,  or  even  at  different  times.  It 
should  be  considered  a  security  violation  when  two  or  more  people 
know  the  password  for  a  user  ID  (except  in  the  case  when  the  SSO 
is  the  other  person  and  the  user  ID  is  identified  by  the  system  as 
having  an  "expired  password").  Note  that  there  is  no  intention  of 
prohibiting  alternate  forms  of  user  identification  (e.g.,  group  IDs, 
functional  titles)  for  non-authentication  purposes  (e.g.,  data  access 
control,  mail).  If  alternate  IDs  are  used,  they  must  be  based  on  user  IDs. 

4. 7.5  User  ID  Revalidation 

The  SSO  should  be  responsible  for  the  development  of  a  procedure 
whereby  prompt  notification  is  given  to  the  SSO  when  a  user  ID 
and  password  must  be  removed  from  the  AD^P  system  (e.g.,  when 
an  employee  leaves  the  sponsoring  organization).  In  addition,  all 
user  IDs  should  be  revalidated  periodically,  and  information  such 
as  sponsor  and  means  of  off-line  contact  (e.g.,  phone  number, 
mailing  address)  updated  as  necessary.  It  is  recommended  that 
this  revalidation  be  done  at  least  once  per  year. 


4.2  User  Responsibilities 

4.2. 1  Security  Awareness 

Users  should  understand  their  responsibility  to  keep  passwords 
private  and  to  report  changes  in  their  user  status,  suspected 
security  violations,  etc.  To  assure  security  awareness  among  the  user 
population,  it  is  recommended  that  each  user  be  required  to  sign  a 
statement  to  acknowledge  understanding  these  responsibilities. 

4.2.2  Changing  Passwords 

The  simplest  way  to  recover  from  the  compromise  of  a  password  is  to 
change  it.  Therefore,  passwords  should  be  changed  on  a  periodic 
basis  to  counter  the  possibility  of  undetected  password 
compromise.  They  should  be  changed  often  enough  so  that  there  is 
an  acceptably  low  probability  of  compromise  during  a  password’s 
lifetime.  To  avoid  needless  exposure  of  users’  passwords  to  the  SSO, 
users  should  be  able  to  change  their  passwords  without 
intervention  by  the  SSO. 

4.2.2. 7  Password  Lifetime 

The  most  obvious  threat  to  the  security  provided  by  a  password 
system  is  from  the  compromise  of  passwords.  The  greater  the  length 
of  time  during  which  a  password  is  used  for  authentication  purposes, 
the  more  opportunities  there  are  for  exposing  it.  In  a  useful  password 
system,  the  probability  of  compromise  of  a  password  increases  during 
its  lifetime.  For  a  period  of  time,  this  probability  could  be  considered 
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acceptably  low  while  after  a  longer  period  of  time,  it  would  be 
considered  unacceptably  high.  At  this  latter  point,  use  of  the 
password  should  be  considered  suspect  rather  than  a  reliable 
proof  of  identity.  By  appropriately  limiting  the  length  of  time 
(called  the  password  lifetime)  during  which  a  password  can  be  used, 
the  vulnerability  of  the  password  can  remain  acceptable. 

There  should  be  a  maximum  lifetime  for  all  passwords.  To 
protect  against  unknown  threats,  it  is  recommended  that  the 
maximum  lifetime  of  a  password  be  no  greater  than  1  year.  The 
presence  of  known  threats  may  indicate  a  need  for  a  shorter 
maximum  lifetime.  Also,  depending  on  the  size  of  the  password  space 
and  on  how  fast  a  penetrator  can  execute  a  login  attempt,  it  may  be 
necessary  to  change  passwords  even  more  frequently.  See  Appendix 
C  for  a  discussion  of  the  relationship  between  password  lifetime, 
password  space,  and  the  guess  rate. 

A  password  should  be  invalidated  at  the  end  of  its  maximum 
lifetime.  It  is  recommended  that,  at  a  pre-determined  period  of 
time  prior  to  the  expiration  of  a  password’s  lifetime,  the  user  ID 
it  is  associated  with  be  notified  by  the  system  as  having  an 
"expired"  password.  A  user  who  logs  in  with  an  ID  having  an 
expired  password  should  be  required  to  change  the  password 
for  that  user  ID  before  further  access  to  the  system  is 
permitted.  If  a  password  is  not  changed  before  the  end  of  its 
maximum  lifetime,  it  is  recommended  that  the  user  ID  it  is 
associated  with  be  identified  by  the  system  as  "locked."  No 
login  should  be  permitted  to  a  locked  user  ID,  but  the  SSO 
should  be  able  to  unlock  the  user  ID  by  changing  the  password 
for  that  user  ID,  following  the  same  rules  that  apply  to  initial 
password  entry  (see  section  4.1.2).  After  a  password  has  been 
changed,  the  lifetime  period  for  the  password  should  be  reset 
to  the  maximum  value  established  by  the  system. 

4.2.2.2  Change  Authorization 

To  be  consistent  with  the  Password  Privacy  control  objective,  users 
(other  than  the  SSO)  should  be  permitted  to  change  only  their 
own  passwords.  To  ensure  this,  it  is  recommended  that  the  user 
enter  the  old  password  and  the  user  ID/password  combination 
be  validated  as  part  of  the  password  changing  procedure. 

4.2.2.3  Change  Procedure 

Changing  a  password  in  a  secure  manner  involves  several  steps.  The 

following  procedure  is  recommended: 

The  procedure  should  be  invoked  at  the  user’s  request  or 
when  a  user  logs  in  with  an  expired  password.  If  the 
change  is  necessary  due  to  an  expired  password,  the  user 
should  be  so  informed.  The  user  should  be  presented  with 
a  brief  summary  of  the  major  steps  in  changing  a 
password,  including  a  caution  that  the  user  should  ensure 
that  no  one  else  is  watching  what  the  user  is  doing.  Except 
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when  the  change  procedure  is  part  of  the  login  procedure 
(e.g.,  logging  in  with  an  expired  password),  the  user’s 
current  password  should  be  entered  to  re-authenticate 
identity.  The  change  procedure  should  display  a  new 
password  for  the  user.  The  new  password  should  be 
different  from  the  old  one  and  should  be  generated  by  an 
algorithm  that  satisfies  the  specifications  in  Appendix  A. 
The  user  should  then  enter  the  new  password  twice  so  the 
procedure  can  verify  that  the  user  can  consistently  enter  the 
password  correctly.  The  new  password  should  be  obliterated 
by  techniques  such  as  overprinting  or  terminal  screen 
erasing.  If  the  two  entered  passwords  are  identical  to  the 
generated  password,  the  password  database  should  be 
updated  (i.e.,  the  old  password  deleted  or  invalidated  and 
the  new  password  associated  with  the  user  ID)  and  a 
message  to  this  effect  should  be  displayed.  Failure  by  the 
user  to  correctly  enter  the  current  password  or  the 
generated  password  should  result  in  a  useful  error 
message  to  the  user  and  in  the  change  procedure  being 
aborted  without  changing  the  password.  When  the  attempt 
to  change  an  expired  password  is  not  successful,  the 
password  should  be  retained  as  expired  and  the  user  given 
the  option  to  again  change  the  password  or  logout.  An 
audit  record  should  be  generated  that  indicates  whether  or 
not  the  change  was  successful. 

4.2.3  Login  to  a  Connected  System 

Users  should  be  required  to  authenticate  their  identities  at  "login" 
time  by  supplying  their  password  along. with  their  user  ID.  It  is 
recommended  that  some  form  of  trusted  identification  forwarding 
be  used  between  hosts  when  users  connect  to  other  ADP  systems 
through  a  network.  When  trusted  identification  forwarding  is  not 
used,  a  remote  host  should  require  the  user’s  ID  and  password 
when  logging  in  through  a  network  connection.  Note  that  user  IDs 
on  different  hosts  for  the  same  user  may  be  different,  and  that 
corresponding  machine-generated  passwords  almost  certainly  will  be 
different.  Note  also  that  a  password  required  by  a  remote  host  is 
vulnerable  to  compromise  by  the  local  host  or  intermediate  hosts. 

4.2.4  Remembering  Passwords 

Since  users  must  supply  their  passwords  to  the  ADP  system  at 
authentication  time,  it  follows  that  they  must  know  what  their  passwords 
are.  It  is  recommended  that  users  memorize  their  passwords  and 
not  write  them  on  any  medium.  If  passwords  must  be  written,  they 
should  be  protected  in  a  manner  that  is  consistent  with  the  damage 
that  could  be  caused  by  their  compromise.  See  Appendix  D  for 
guidance  on  the  protection  of  passwords. 
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4.3  Authentication  Mechanism  Functionality 

4.3.1  Internal  Storage  of  Passwords 

It  is  normally  necessary  for  the  ADP  system  to  store  internally  the  user 
ID  for  each  authorized  system  user  as  well  as  some  representation  of  the 
password  and,  when  required,  the  clearance  and  authorizations  that  are 
associated  with  each  user  ID.  Without  some  form  of  access  control  over 
this  information,  it  will  be  possible  for  unauthorized  users  to  read  and/or 
modify  the  password  database.  Unauthorized  reading  and  writing  of  the 
password  database  are  a  concern.  Reading  it  could  result  in  disclosure  of 
passwords  to  unauthorized  users.  Being  able  to  write  it  could  result,  for 
example,  in  user  A  changing  user  B’s  password  so  user  A  could  log  in 
under  user  B’s  identity.  Note  that  it  is  necessary  for  the  login  process  to 
be  able  to  read  the  password  database  and  the  password  changing  process 
to  be  able  to  read  and  write  the  password  database. 

Stored  passwords  should  be  protected  by  access  controls  provided 
by  the  ADP  system,  by  password  encryption,  or  by  both. 

4.3. 1. 1  Use  of  Access  Control  Mechanisms 

Access  control  mechanisms  (e.g.,  mandatory  or  discretionary 
controls  as  discussed  in  CSC-STD-001-83)  should  be  used  to 
protect  the  password  database  from  unauthorized 
modification  and  disclosure. 

4.3. 1.2  Use  of  Encryption 

Encryption  of  stored  passwords  should  be  used  whenever  the 
access  control  mechanisms  provided  by  the  ADP  system  are 
not  adequate  to  prevent  exposure  of  the  stored  passwords.  It  is 
recommended  that  password  encryption  be  used  even  when 
other  access  controls  are  considered  adequate,  as  this  helps 
protect  against  possible  exposure  when  access  controls  are  bypassed 
(e.g.,  system  dumps).  When  encryption  is  used  to  protect  stored 
passwords,  it  is  recommended  that  the  algorithm  meet  the 
specifications  in  Appendix  B.  It  is  recommended  that 
encryption  be  done  immediately  after  entry,  that  the  memory 
containing  the  plaintext  password  be  erased  immediately  after 
encryption,  and  that  only  the  encrypted  password  be  used  in 
comparisons.  There  is  no  need  to  be  able  to  decrypt  passwords. 
Comparisons  can  be  made  by  encrypting  the  password  entered  at 
login  and  comparing  the  encrypted  form  with  the  encrypted  password 
stored  in  the  password  database. 


4.3.2  Entry 

Passwords  should  be  entered  after  providing  a  user  ID  to  the 
system.  If  the  entry  is  correct,  the  system  should  then  display  the 
date  and  time  of  the  user’s  last  login. 

It  is  recommended  that  the  system  not  echo  passwords  that  users 
type  in.  When  the  system  cannot  prevent  a  password  from  being 
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echoed  (e.g.,  in  a  half-duplex  connection),  it  is  recommended  that  a 
random  overprint  mask  be  printed  before  or  after  the  password  is 
entered,  as  appropriate,  to  conceal  the  typed  password. 

The  complete  password  as  entered  by  the  user  should  be  an  exact 
match,  character  for  character,  with  the  user’s  current  password. 

4.3.3  Transmission 

During  transmission  of  a  password  from  a  user’s  terminal  to  the 
computer  in  which  the  authentication  is  done,  passwords  should 
be  protected  in  a  manner  that  is  consistent  with  the  damage  that 
could  be  caused  by  their  compromise.  Since  passwords  are  no  more 
sensitive  than  the  data  they  provide  access  to,  there  is  generally  no  reason 
to  protect  them,  during  transmission,  to  any  greater  degree  (e.g., 
encryption)  than  regular  data  is  protected.  See  Appendix  D  for  guidance 
on  the  protection  of  passwords. 

4.3.4  Login  Attempt  Rate 

By  controlling  the  rate  at  which  login  attempts  can  be  made  (where  each 
attempt  constitutes  a  guess  of  a  password),  the  number  of  guesses  a 
penetrator  can  make  during  a  password’s  lifetime  is  limited  to  a  known 
upper  bound.  To  control  attacks  where  a  penetrator  attempts  many 
logins  through  a  single  access  port,  the  password  guess  rate  should  be 
controlled  on  a  per-access  port  basis.  That  is,  each  access  port 
should  be  individually  controlled  to  limit  the  rate  at  which  login 
attempts  can  be  made  at  each  port.  When  a  penetrator  can  easily 
switch  among  multiple  access  ports,  it  is  recommended  that  the 
password  guess  rate  also  be  controlled  on  a  per-user  ID  basis. 

It  is  recommended  that  maximum  login  attempt  rates  fall  within 
the  range  of  one  per  second  to  one  per  minute.  This  range  provides 
reasonable  user-friendliness  without  permitting  so  many  login  attempts 
that  an  extremely  large  password  space  or  an  extremely  short  password 
lifetime  is  necessary.  See  Appendix  C  for  a  discussion  of  the  relationship 
between  the  guess  rate,  password  lifetime,  and  password  space. 

Note  that  it  is  not  intended  that  login  be  an  inherently  slow  procedure,  for 
there  is  no  reason  to  delay  a  successful  login.  However,  in  the  event  of  an 
unsuccessful  login  attempt,  it  is  quite  reasonable  to  use  an  internal  timer 
to  enforce  the  desired  delay  before  permitting  the  next  login  attempt. 
The  user  should  not  be  able  to  bypass  this  procedure. 

4.3.5  Auditing 
4.3.5. 1  Audit  Trails 

The  system  should  be  able  to  create  an  audit  trail  of  password 
usage  and  changes.  Such  an  audit  trail  should  not  contain 
actual  passwords  or  character  strings  that  were  incorrectly 
given  as  passwords,  since  this  could  expose  the  password  of  a 
legitimate  user  who  mistyped  his  user  ID  or  password.  Auditable 
events  should  include:  successful  login,  unsuccessful  login 
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attempts,  use  of  the  password  changing  procedure,  and  the 
locking  of  a  user  ID  due  to  its  password  reaching  the  end  of  its 
jifetime.  For  each  recorded  event,  the  audit  record  should 
include:  date  and  time  of  the  event,  type  of  event,  offered  user 
ID  for  unsuccessful  logins  or  actual  user  ID  for  other  eVents, 
and  origin  of  the  event  (e.g.,  terminal  or  access  port  ID).  Audit 
records  of  password  changes  should  also  indicate  whether  or 
not  the  change  was  successful. 

4.3.5.2  Real-time  Notification  to  System  Personnel 

It  is  recommended  that  each  accumulation  of  5  consecutive 
unsuccessful  login  attempts  from  a  single  access  port  or 
against  a  single  user  ID  results  in  immediate  notification  of  the 
event  to  the  ADP  system  operator  or  the  SSO.  While  there  is  no 
requiren  ant  for  the  SSO  or  operator  to  take  any  action  upon 
receiving  the  notification,  frequent  notifications  may  indicate  that  a 
penetration  attempt  is  in  progress  and  may  warrant  investigation 
and  possible  corrective  action. 

4.3.5.3  Notification  to  the  User 

Upon  successful  login,  the  user  should  be  notified  of: 

*  The  date  and  time  of  user’s  last  login; 

*  The  location  of  the  user  (as  can  best  be  determined)  at  last 
login;  and 

*  Each  unsuccessful  login  attempt  to  this  user  ID  since  the 
last  successful  login. 

This  provides  a  means  for  the  user  to  determine  if  someone  else  is 
using  or  attempting  to  guess  this  user  ID  and  password. 


4.4  Password  Protection 

4.4. 1  Single  Guess  Probability 

The  probability  that  any  single  attempt  at  guessing  a  password  will  be 
successful  is  one  of  the  most  critical  factors  in  a  password  system.  This 
probability  depends  on  the  size  of  the  password  space  and  the  statistical 
distribution  within  that  space  of  passwords  that  are  actually  used.  Since 
many  user-created  passwords  are  particularly  easy  to  guess,  all 
passwords  should  be  machine-generated  using  an  algorithm  that 
meets  the  specifications  in  Appendix  A. 

4.4.2  Password  Distribution 

During  distribution  to  the  user,  passwords  should  be  protected  to 
the  same  degree  as  the  information  to  which  they  provide  access. 
Machine-genehated  passwords  should  be  displayed  on  the  user’s 
terminal  at  time  of  change,  alonjg  with  appropriate  cautions  to  the 


user  to  protect  the  password.  At  the  completion  of  the  change 
procedure,  it  is  recommended  that  displayed  passwords  be  erased 
or  overstruck,  as  appropriate  for  the  terminal  type.  Passwords 
changed  by  the  SSO  should  be  distributed  in  a  manner  that  is 
consistent  with  the  damage  that  could  be  caused  by  their 
compromise.  See  Appendix  D  for  guidance  on  the  protection  of 
passwords. 
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APPENDIX  A 

Password  Generation  Algorithm 


This  appendix  describes  the  requirements  to  be  met  by  an  acceptable  password 
generation  algorithm.  The  issues  involved  relate  to  the  specifications  for  password 
space,  random  seed  generation,  pseudo-random  number  generation  and  "user- 
friendly"  passwords. 


A.l  Password  Space 

The  size  of  the  password  space  is  a  function  of  the  size  of  the  alphabet  and  the 
number  of  characters  from  that  alphabet  that  are  used  to  create  passwords.  (The 
maximum  size  of  the  password  space  can  be  expressed  as  S  =  Am  where  S  is  the 
maximum  password  space,  A  is  the  alphabet  size  and  M  is  the  password  length.) 
To  determine  the  minimum  size  of  the  password  space  needed  to  satisfy  the 
security  requirements  for  an  operational  environment,  equation  [3]  in  Appendix  C 
can  be  used.  The  password  generation  algorithm  selected  should  be  able  to 
generate  at  least  that  number  of  passwords.  In  addition,  the  generated 
passwords  should  be,  at  a  minimum,  6  characters  in  length. 


A.2  Random  Seeds 

When  a  pseudo-random  number  generator  is  used  in  a  password 
generation  algorithm,  it  should  accept  as  input  random  data  that  would 
provide  output  which  has  a  high  degree  of  unpredictability.  This  random 
data  (seed)  can  be  derived  from  a  number  of  available  parameters  such  as  a  system 
clock,  system  registers,  date,  time,  etc.  The  parameters  should  be  selected  to 
ensure  that  the  number  of  unique  seeds  that  can  be  generated  from  these 
inputs  should  be  at  least  equal  to  the  minimum  number  of  passwords  that 
must  be  generated.  When  passwords  are  used  to  protect  classified 
information,  the  seed  generator  should  be  approved  by  the  DoD  Computer 
Security  Center. 


A. 3  Pseudo-Random  Number  Generator 

Using  a  random  seed  as  input,  the  pseudo-random  number  generator  that 
drives  a  password  generation  algorithm  should  have  the  property  that 
each  bit  in  the  pseudo-random  number  that  it  generates  is  a  complex 
function  of  all  the  bits  in  the  seed.  The  Federal  Data  Encryption  Standard 
(DES),  as  specified  in  FIPS  46,  (9)  is  an  example  of  a  pseudo-random  number 
generator  with  this  property.  If  DES  is  used,  it  is  suggested  that  the  64-bit  Output 
Feedback  (OFB)  mode  be  used  as  specified  in  FIPS  81  (10).  In  this  case,  the  seed 
used  as  input  could  consist  of: 


*  An  initialization  vector 

*  A  cryptographic  key 

*  Plain  text 


V 
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Factors  that  can  be  used  as  input  to  these  parameters  are: 

For  the  initialization  vector: 

*  System  clock 

*  System  ID 

*  User  ID 

*  Date  and  time 

For  the  cryptographic  key: 

*  System  interrupt  registers 

*  System  status  registers 

*  System  counters 

The  plain  text  can  be  an  external  randomly  generated  64-bit  value  (8  characters 
input  by  the  SSO). 

The  resulting  pseudo-random  number  that  is  output  will  be  the  64  bits  of  cipher 
text  generated  in  the  64-bit  OFB  mode.  The  password  generation  algorithm  can 
either  format  this  pseudo-random  number  into  a  password  or  use  it  as  an  index  (or 
indices)  into  a  table  and  use  the  contents  from  this  table  to  form  a  password  or  a 
passphrase. 


A.4  "User-Friendly”  Passwords 

To  assist  users  in  remembering  their  passwords,  the  password  generation 
algorithm  should  generate  passwords  or  passphrases  that  are  "easy"  to 
remember.  Passwords  formed  by  randomly  choosing  characters  are  generally 
difficult  to  remember.  Passwords  that  are  pronounceable  are  often  easy  to 
remember,  as  are  passphrases  that  are  formed  by  concatenating  real  words  into  a 
phrase  or  sentence. 
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APPENDIX  B 

Password  Encryption  Algorithm 


Password  encryption  is  advocated  as  a  password  protection  measure.  The  algorithm 
selected  for  this  would  be  determined  by  the  system  environment.  Some 
environments  may  require  that  a  classified  encryption  algorithm  be  used,  while  for 
other  environments  an  unclassified  algorithm  would  be  required. 


B.l  Encryption  Algorithm 

A  conventional  or  public  key  cryptographic  algorithm  which  is  configured  as  a 
"one-way"  encryption  algorithm  may  be  used  for  password  encryption,  but 
whatever  algorithm  is  used,  the  protection  the  encryption  algorithm  provides 
should  rely  on  its  complexity.  If  there  is  a  key  that  can  be  used  with  the 
algorithm  to  decrypt  passwords,  that  key  should  not  be  stored  in  the  ADP 
system. 


B.2  Assurance  for  Unique  Encrypted  Passwords 

If  a  password  encryption  system  depends  only  on  the  password  and  other  fixed 
information,  there  is  a  possibility  that  two  different  users  will  have  identical 
encrypted  passwords.  A  user  who  discovers  another  user  with  an  identical 
encrypted  password  will  then  know  that  the  same  password  will  work  for  both  user 
IDs  even  if  they  don’t  have  identical  plaintext  passwords.  To  minimize  this 
possibility,  it  is  recommended  that  the  encryption  algorithm  use  the  ADP 
system  name  (in  network  environments)  and  the  user’s  ID  as  factors  in  the 
encryption.  (This  can  be  easily  accomplished  by  concatenating  the  system  ID, 
user  ID  and  password,  and  then  applying  the  encryption  algorithm  to  the  resulting 
string.) 
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APPENDIX  C 

Determining  Password  Length 


The  security  afforded  by  passwords  is  determined  by  the  probability  that  a  password 
can  be  guessed  during  its  lifetime.  The  smaller  that  probability,  the  greater  the 
security  provided  by  the  password.  All  else  being  equal,  the  longer  the  password,  the 
greater  the  security  it  provides.  This  appendix  reviews  the  mathematics  involved  in 
establishing  how  long  a  password  should  be. 

The  basic  parameters  that  affect  the  length  of  the  password  needed  to  provide  a 
given  degree  of  security  are: 

L  =  maximum  lifetime  that  a  password  can  be  used  to  log  into  the  system. 

P  =  probability  that  a  password  can  be  guessed  within  its  lifetime,  assuming 
continuous  guesses  for  this  period. 

R  =  number  of  guesses  per  unit  of  time  that  it  is  possible  to  make. 

S  =  password  space,  i.e.,  the  total  number  of  unique  passwords  that  the  password 
generation  algorithm  can  generate. 


C.l  Relationship 

Considering  only  the  cases  where  S  is  greater  than  L  x  R  and  therefore  P  is  less 
than  1,  the  relationship  between  these  parameters  is  expressed  by  the  equation: 

P  =  LxR  [1] 

A  detailed  explanation  of  the  derivation  of  this  basic  equation  is  ffiven  in 
Appendix  F. 


C.2  Guess  Rate 

Several  factors  contribute  to  the  rate  at  which  attempts  can  be  made  to  gain  access 
to  the  data  on  a  system  when  a  valid  password  is  not  known.  First  and  foremost  is 
the  protection  given  to  the  password  data  base  itself.  If  the  password  data  base  is 
unprotected  (i.e.,  can  be  read  by  anyone  as  ordinary  data),  then  "guessing"  may 
not  be  required. 

If  the  password  data  base  can  be  read,  but  the  passwords  are  encrypted  (see 
Appendix  B),  a  very  high  guess  rate  may  be  possible  by  using  a  computer  to  try  a 
dictionary  of  possible  passwords  to  see  if  ciphertext  can  be  generated  that  is  the 
same  as  one  in  the  password  data  base.  A  similar  situation  frequently  occurs 
where  only  passwords  are  used  to  protect  files. 
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Finally,  if  the  password  data  base  has  effective  access  controls  and  the  login 
procedure  cannot  be  bypassed,  the  guess  rate  can  be  controlled  by  setting  limits  on 
the  number  of  login  or  other  attempts  that  can  be  made  before  terminating  the 
connection  or  process. 


C.3  Password  Lifetime 

All  other  things  being  equal,  the  shorter  the  lifetime  of  a  password,  the  fewer  the 
number  of  guesses  that  can  be  made  and  thus  the  greater  the  degree  of  password 
security.  As  stated  in  4.2.2.1,  the  maximum  password  lifetime  should  not 
exceed  one  year. 


C.4  Password  Space 

Password  length  and  alphabet  size  are  factors  in  computing  the  maximum 
password  space  requirements.  Equation  [2]  expresses  the  relationship  between  S, 
A,  and  M  where: 

S  =  password  space 
A  =  number  of  alphabet  symbols 
M  =  password  length 

S  =  AM  [2] 

To  illustrate:  If  passwords  consisting  of  4  digits  using  an  alphabet  of  10  digits 
(e.g.,  0-9)  are  to  be  generated: 

S  =  104 

That  is,  10,000  unique  4-digit  passwords  could  be  generated. 

Likewise,  to  generate  random  6-character  passwords  from  an  alphabet  of  26 
characters  (e.g.,  A-Z): 

S  =266 

That  is  3.089  *  108  unique  6-character  passwords  could  be  generated. 

"User-friendly"  passwords  (sometimes  referred  to  as  passphrases)  could  be 
generated  by  using,  for  example,  3  symbols  from  an  alphabet  (dictionary)  of  2000 
symbols,  where  each  symbol  was  a  pronounceable  word  of  4,  5,  or  6  characters. 
Using  equation  [2]  and  setting: 

A  =  2000  symbols  (words) 

M  =  3 


Then  S  =  20003 

That  is,  8  *  109  unique  passwords  could  be  generated  where  each  password  was 
made  up  of  3  words  taken  from  a  dictionary  of  2000  words. 
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C.5  A  Procedure  for  Determining  Password  Length 

What  is  important  in  using  passwords  is  how  long  to  make  the  password  to  resist 
exhaustive  penetration  attacks.  We  can  do  this  by  using  the  following  procedure: 

a.  Establish  an  acceptable  probability,  P,  that  a  password  will  be  guessed  during 
its  lifetime.  For  example,  when  used  as  a  login  authenticator,  the  probability  may 
be  no  more  than  1  in  1,000,000.  In  another  case,  where  very  sensitive  data  is 
involved,  the  value  for  P  may  be  set  at  10-20. 

b.  Solve  for  the  size  of  the  password  space,  S,  with  the  equation  derived  from 
equation  [1] 

S  =  £  [3] 

where  G  =  L  x  R 


c.  Determine  the  length  of  the  password,  M,  from  the  equation 

M  =  _ logS _ 

log  (number  of  symbols  in  the  "alphabet”) 


[4] 


M  will  generally  be  a  real  number  that  must  be  rounded  up  or  down  to  the  nearest 
whole  number.  Examples  of  calculating  many  of  the  values  described  above  are 
given  below. 


C.6  Worked  Examples 

An  example  shown  here  is  drawn  from  a  real  network  case.  The  problem  is  to 
determine  the  needed  password  length  to  reduce  to  an  acceptable  level  the 
probability  that  a  password  will  be  guessed  during  its  lifetime. 

The  network  to  which  this  is  applied  supports  both  a  300-baud  and  a  1200-baud 
service.  Experiments  on  the  network  have  determined  that  it  is  possible  to  make 
about  8.5  guesses  per  minute  on  the  300-baud  service  and  14  guesses  per  minute 
on  the  1200-baud  service.  (The  reason  that  the  "guess  rate”  for  the  1200-baud 
service  is  not  4  times  that  of  the  300-baud  service  is  that  the  system  response  time, 
which  is  not  affected  by  the  improved  transmission  speed,  becomes  the  limiting 
factor  in  how  many  guesses  can  be  accomplished  in  a  given  amount  of  time.) 

In  this  example,  the  arbitrary  value  of  10-6  is  used  for  the  probability  (P)  of 
guessing  the  password  in  its  lifetime.  As  we  will  see  below,  the  password  lifetime 
is  not  the  critical  factor  here  as  long  as  the  password  is  changed  at  least  once  per 
year. 

The  statement  of  the  problem  is  to  find  a  password  length  that  will  resist  being 
guessed  with  a  probability  of  1  in  106  in  1  year  of  continuous  guesses. 

When  three  parameters  in  equation  [1]  are  known,  the  fourth  value  can  be  found. 
To  find  the  password  space  required  by  our  examples,  the  following  parameters  are 
given: 


20 


L  is  set  for  6  months  and  12  months. 

P  is  set  for  1  in  1,000,000  (acceptable  probability  of  guessing  the  password). 

R  is  set  at  8.5  guesses  per  minute  (guess  rate  possible  with  300-baud  service). 

At  8.5  guesses  per  minute,  the  number  of  guesses  per  day  would  be  12,240. 

Substituting  183  days  for  6  months  then  using  equation  [3], 

g  G  _  183  x  12240  _  2.23992  x  1012  passwords 

P  .000001 

The  12-month  value  is  twice  that  of  the  6-month  case. 

With  this  data,  and  using  equation  [4],  we  can  determine  the  length  of  the 
passwords  as  a  function  of  the  size  of  the  alphabet  from  which  they  are  drawn.  We 
will  assume  two  alphabet  sizes:  a  26-letter  alphabet  and  a  36-letter-and-number 
alphabet. 


M  = 

loff  (2.23992x1012)  =  3.72 

log  26 

(for  6-month  lifetime) 

M  = 

loe  (4.4676x1012)  =  8.94 

log  26 

(for  12-month  lifetime) 

M  = 

Ion  (2.23992x1012)  =  7.93 

log  36 

(for  6-month  lifetime) 

M  = 

loe  (4.4676x1012)  =  g.13 

log  36 

(for  12-month  lifetime) 

Table  1  presents  the  results. 


TABLE  1 


MAXIMUM 

LIFETIME 

(months) 

Length  of  Password 

26-Character  alphabet 

36-Character  alphabet 

6 

9 

(rounded  up  from  8.72) 

8 

(rounded  up  from  7.93) 

12 

9 

(rounded  up  from  8.94) 

8 

(rounded  down  from  8.13) 
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C.7  Passphrases 

A  "passphrase"  is  a  concatenation  of  words  drawn  from  a  dictionary.  The 
dictionary  is  merely  the  collection  of  symbols  making  up  the  "alphabet"  from 
which  the  password  is  generated.  As  an  example,  suppose  the  passphrase  is  made 
up  of  words  drawn  from  a  dictionary  of  4,  5  and  6  letter  words.  There  are 
approximately  3,780  4-letter  words,  7,500  5-letter  words  and  12,000  6-letter  words 
in  English.  The  "alphabet  size"  for  generating  passphrases  is  approximately 
23,300. 

We  can  compute  how  many  words,  drawn  at  random  from  the  dictionary  of  23,300 
words,  are  needed  to  produce  a  passphrase  that  will  be  resistant  to  exhaustive 
attack  with  the  probability  of  1  x  10-6. 

We  have  to  solve  for  S  as  before,  and  from  that,  solve  for  M,  the  length  of  the 
password  (i.e.,  number  of  alphabet  symbols  or  words). 


For  L  =  12  months,  S  =  4.4676  *  1012,  logS  =  12.6500 

ForL  =  6 months,  S  =  2.2399  *  1012,  logS  =  12.3502 

Log  23300  =  4.3669 
Using  equation  (4)  we  obtain: 

For  L  =  12  months  M  =  12.6500  =  3  (rounded  from  2.89) 

4.3669 

For  L  =  6  months  M  =  12.3502  =  3  (rounded  from  2.82) 

4.3669 

Thus,  for  the  passphrase  algorithm  described,  namely  selection  at  random  from  a 
dictionary  of  23,300  words,  only  3  words  are  needed  in  a  passphrase  to  obtain  the 
desired  resistance  to  exhaustive  enumeration.  In  using  the  algorithm,  each  word 
of  the  phrase  is  drawn  independently  from  the  dictionary.  This  may  result  in  a 
word  appearing  more  than  once  in  the  passphrase. 
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APPENDIX  D 

Protection  Basis  for  Passwords 


Passwords  are  used  to  prevent  people  who  have  physical  access  to  an  ADP  system 
from  gaining  access  to  data  belonging  to  another  user.  Thus,  a  password  should 
be  protected  in  a  manner  that  is  consistent  with  the  damage  that  might  be 
caused  by  its  exposure  to  someone  who  has  the  opportunity  to  use  it  (i.e.,  has 
physical  access  to  the  ADP  system  terminals).  Exposure  of  a  password  to  someone 
who  is  physically  prevented  from  attempting  to  use  it  is  not  a  threat. 


D.l  Systems  Containing  Only  Unclassified  Information 

Although  an  ADP  system  may  process  only  unclassified  information,  it  still  may 
require  that  the  data  be  protected  from  unauthorized  use.  Although  the  password 
is  unclassified,  the  obligation  remains  that  the  user  protect  this  password  so 
that  only  those  with  a  need-to-know  can  access  the  data. 


D.2  Systems  Containing  Classified  Information 

Passwords  that  are  used  in  ADP  systems  that  operate  in  the  dedicated  or 
system  high  security  modes  (3)  should  not  be  classified,  but  should  be 
protected  to  the  same  degree  as  For  Official  Use  Only  information.  In  this 
case,  there  is  no  need  to  classify  passwords  since  access  to  the  area  in  which  the 
system  resides  is  restricted  to  those  with  a  clearance  as  high  as  the  highest 
classification  level  of  the  information  processed.  A  person  who  obtained  a 
password  for  a  system  running  in  dedicated  or  system  high  security  mode  but  who 
did  not  possess  the  proper  security  clearance  would  be  unable  to  gain  physical 
access  to  the  system  and  use  the  password. 

For  systems  operating  in  the  multilevel  security  mode  (3),  passwords  may  or  may 
not  have  to  be  classified. 

When  the  ability  to  access  classified  information  is  based  on  the  physical 
protection  of  the  terminal  rather  than  on  the  identity  of  the  user  (i.e.,  when 
all  terminals  are  single-level  devices),  passwords  should  not  be  classified, 
but  should  be  protected  to  the  same  degree  as  For  Official  Use  Only 
information.  There  is  no  need  to  classify  passwords  that  can  only  be  used  on 
single-level  terminals,  since  physical  access  to  single-level  terminals  is  controlled 
to  the  level  associated  with  the  terminal.  When  the  ability  to  access  classified 
information  is  based  on  the  user’s  identity  and  is  not  restricted  by  the  level 
of  the  terminal  (i.e.,  multilevel  terminals),  each  password  must  be  classified 
to  the  highest  level  of  the  information  to  which  it  provides  access. 

When  multilevel  terminals  are  used,  the  system  determines  the  user’s  access 
authorizations  to  classified  material  based  on  his  identity,  and  authenticates  the 
identity  by  requiring  a  password.  Thus,  the  ADP  system  can  protect  the 
information  it  processes  only  to  the  extent  that  passwords  are  protected.  For 
example,  a  user  with  a  Secret  clearance  can  access  Secret  information. 
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Compromise  of  that  user’s  password  could  result  in  the  compromise  of  Secret 
information;  therefore,  the  password  would  be  classified  Secret.  In  the  case  of  a 
system  with  multilevel  terminals,  disclosure  of  a  Top  Secret  user’s  password  co  a 
Secret  user  would  allow  the  Secret  user  to  login  as  the  Top  Secret  user  and  thus 
gain  access  to  Top  Secret  information.  Disclosure  of  Top  Secret  information  to 
someone  with  only  a  Secret  clearance  can  cause  exceptionally  grave  damage  to  the 
national  security.  Since  disclosure  of  the  Top  Secret  user’s  password  could  lead  to 
this,  the  password  must  be  classified  Top  Secret  (5). 

Note  that  classified  passwords  must  not  be  used  on  terminals  that  are  not 
authorized  for  data  at  the  level  of  the  password  (e.g.,  a  Top  Secret  password  must 
not  be  used  on  a  Secret  terminal).  The  presence  of  both  single-level  and  multilevel 
terminals  on  a  system  may  indicate  the  need  for  passwords  at  each  security  level. 
At  a  minimum,  an  unclassified  password  should  be  available  for  use  on 
terminals  that  are  only  authorized  for  unclassified  data. 


APPENDIX  E 

Features  for  Use  in  Very  Sensitive  Applications 
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The  following  features  can  be  used  to  enhance  the  security  provided  by  a  password 
system.  Because  they  are  somewhat  "user-unfriendly,"  they  are  recommended  for 
environments  only  when  there  is  a  high  threat  of  password  compromise. 


E.l  One-Time  Passwords 

One-time  passwords  (i.e.,  those  that  are  changed  after  each  use)  are  useful  when 
the  password  is  not  adequately  protected  from  compromise  during  login  (e.g.,  the 
communication  line  is  suspected  of  being  tapped).  The  difficult  part  of  using  one¬ 
time  passwords  is  in  the  distribution  of  the  new  passwords.  If  a  one-time  password 
is  changed  often  because  of  frequent  use,  the  distribution  of  new  one-time 
passwords  becomes  a  significant  point  of  vulnerability.  There  are  products  on  the 
market  that  generate  such  passwords  through  a  cryptographic  protocol  between 
the  destination  host  and  a  hand-held  device  the  user  can  carry. 


E.2  Failed  Login  Attempt  Limits 

In  some  instances,  it  may  be  desirable  to  count  the  number  of  unsuccessful  login 
attempts  for  each  user  ID  and  to  base  password  expiration  and  user  ID  locking  on 
the  actual  number  of  failed  attempts.  (Changing  a  password  would  reset  the  count 
for  that  user  ID  to  zero.)  For  example,  the  password  could  be  identified  as  expired 
after  100  failed  login  attempts,  and  the  user  ID  locked  after  500. 
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APPENDIX  F 

On  the  Probability  of  Guessing  a  Password 


Appendix  C  discusses  the  techniques  for  finding  a  password  length  that  will  resist 
exhaustive  enumeration  over  the  lifetime  of  the  password  with  a  given  probability. 
This  appendix  derives  the  probability  of  guessing  a  password  during  its  lifetime. 

As  in  Appendix  C,  we  use  the  parameters: 

L  =  password  lifetime 
R  =  guess  rate 

S  =  size  of  the  password  space 

P  =  probability  of  guessing  a  password  during  its  lifetime 

The  total  number  of  guesses,  (G),  that  can  be  made  during  a  password’s  lifetime  is: 

G  =  R  x  L  [1] 

At  this  point,  we  need  to  consider  the  relation  of  the  size  of  the  password  space,  S,  to 
G.  Clearly,  if  S  is  so  small  that  one  could  try  all  possible  passwords  before  the 
lifetime  of  the  password  expires,  the  probability  of  guessing  the  password  is  1.  As  a 
result,  we  consider  only  cases  where  S  is  greater  than  G. 

The  probability  question  then  is,  "For  the  case  where  S  is  greater  than  G,  what  is  the 
probability  that  in  G  guesses  the  password  will  be  guessed?"  This  is  the  same  as 
asking  the  question,  "What  is  the  probability  that  in  the  lifetime  of  the  password,  it 
will  be  guessed?"  The  probability  sought  is: 

How  many  ways  one  can  make  G  guesses  (of  S  objects) 

p  =  _  that  include  the  password _ 

How  many  different  ways  one  can  make  G  guesses  of  S  objects 

Note  that  the  probability  that  is  appealed  to  is  of  the  simplest  form.  It  is  derived 
from  the  definition  of  probability  that  the  probability  of  an  event  is  given  by  the 
number  of  ways  the  event  can  happen  divided  by  the  number  of  ways  an  event  can 
happpen  or  fail. 

We  first  observe  that  the  total  number  of  ways  one  can  make  G  guesses  of  S  things  is 
given  by  sCg  (the  combinatorial  notation  that  means  the  number  of  combinations  of 
'  s"  things  taken  "g"  at  a  time).  (Lower  case  letters  are  used  with  the  combinatorial 
notation  in  order  to  make  the  expressions  more  readable.)  This  is  determined  by: 

s! 

g!(s  -  g)! 

Thus,  if  S  =  A,B,C,D,E,  one  could  make  3  guesses  in  5C3  different  ways, 

5*4*3*2*l/3*2*l*2*l  =  iq. 
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(Enumerating,  they  are  ABC,ABD,ABE,ACD,ACE,ADE,BCD,BCE,BDE,CDE.) 

The  problem  of  finding  the  number  of  guesses  of  this  total  that  include  a  specific 
password,  e.g.,  an  "A”,  is  addressed  by  considering  a  reduced  set  without  the  specific 
password  and  asking  how  many  ways  one  can  make  G  guesses  with  the  reduced  set. 
Then,  the  total  number  of  ways  to  make  G  guesses  that  include  the  specified 
password  is  the  difference  between  the  two  values.  This  is  given  by: 

sCg-  (s-l)Cg  [2] 

That  is,  remove  the  designated  password  from  the  set  S,  compute  the  number  of  ways 
of  making  G  guesses  without  the  password,  then  consider  the  difference  between  the 

two  values. 

If  we  ask  in  our  example  how  many  ways  to  make  3  guesses  that  do  NOT  include  a 
particular  password  from  the  set  of  5  (say  an  A  ),  this  is  given  by. 

4C3  =  4*3*2*1/3*2*1*1  =  4 

Enumerating  for  the  specific  case  of  an  "A",  they  are  BCD,BCE,BDE,CDE. 

The  number  of  ways  to  make  3  guesses  that  include  the  designated  element  is 
10-4  =  6.  Thus,  the  probability  of  guessing  a  designated  password  in  3  guesses  is 
6/10  or  .6. 


Simplification: 

It  is  indeed  fortuitous  that  there  is  a  theorem  in  any  number  of  books  on  Probability 
Theory  that  states: 

nCr  =  (n-l)C(r-l)  +  (n-l)Cr  [3] 

This  may  also  be  expressed  as: 

nCr  -  (n-l)Cr  =  (n-l)C(r-l)  [4] 

Substituting  s  for  n  and  g  for  r  we  obtain  the  expression: 

(s-l)C(g-l)  [5] 

for  the  number  of  ways  of  making  G  guesses  that  include  a  specific  password.  Then 
the  probability  that  a  given  password  will  be  guessed  during  the  lifetime  ot  that 
password  is  given  by: 


P  =  (s-l)C(g-l). 
sCg 


[6] 
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Evaluating  this  expression  gives: 


This  derivation  of  the  probability  of  guessing  a  password  during  its  lifetime,  i.e., 

P  =  |  [8] 


is  important  in  that  it  allows  us  to  derive  the  size  of  the  password  space 
S  =  £  [9] 

given  an  acceptable  probability  of  not  guessing  the  password  during  its  lifetime. 
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